Subject: Re: DLSw Capabilities Exchange Format Proposal

From: [email-masked] (Paul Brittain)
Date: Wed, 9 Feb 94 17:05:05 GMT

Wayne,

Thanks for the detailed proposal on Capabilities Exchange.  It's a bit of a
soul-destroying task to have to define something that is still very fluid and
not entirely under your control - but all the more reason why a strawman
such as this is important.

At the detailed level I have a few comments and have annotated them in the
copy of your mail below.  However there are a number of broader points that we
will also need to discuss in Anaheim:

-       How is the Capabilities Exchange sent over the SSP transport?

        I assume it will just be an additional SSP control frame type which
        contains no DLC header but has a data content of precisely the
        GDS variable you propose.

-       When exactly does the exchange occur - as the first message only?

        This is particularly important for interoperation with pre-standard
        DLSw implementations which may get upset at the appearance of an
        unexpected SSP message type.  Maybe we should perform the exchange on
        the 'reverse' TCP/IP flow where a pre-standard DLSw will not look for
        it, or use a third 'admin' port?

-       How does a standard DLSw detect that it is dealing with a pre-standard
        DLSw partner?

        Obviously by lack of a Capabilities Exchange message, but this ties
        in with the how the exchange is sent over the SSP transport.

More detailed points comments are listed in the message appended below.

See you next week.

Paul Brittain
+44 244 313440

Appended Message:
=================

> To: [email-masked]
> Subject: DLSw Capaabilities Exchange Format Proposal
> Date: Tue, 08 Feb 94 13:08:02 PST
> From: [email-masked]
> Status: RO
>
> Attached below is my proposal for the format of the Capabilities
> Exchange between two DLSw standard compliant devices.
>
> There are still a couple of gaps in the format specification:
>     (1) GDS Id assignments
>     (2) Key assignments for structured subfields
>
> I've assigned them what I think are reasonable values awaiting a
> verdict from  IBM.  IBM DLSw reps are working with the IBM architecture
> group to come up with assignments.  (Hopefully the patent on GDS
> Variables won't get in the way!)
>
> I tried to capture the direction of the other SIGlets that affected
> Capabilities Exchange (especially Flow Control).  There hasn't really
> been any convergence yet, but I've written them down anyway.  I'm sure
> the results of next week's AIW will affect the format of the
> Capabilities Exchange.  C'est la vie.
>
> Please look this over and comment on the overall structure of the format.
> Alternatives on the format as I see it are:
>     (a) a single GDS Variable with individual variables in structured
> 	subfields,
>     (b) multiple GDS Variables logically grouped together, each with
> 	individual variables in structured subfields,
>     (c) individual variables in their own GDS Variables with possibly
> 	no structured subfields.
>
> Alternative (a) is the one I've chosen in this proposal since that is
> roughly what both the APPC GDS Variables (e.g. CNOS Request/Reply) and
> APPN GDS Variables (e.g. CP Capabilities Exchange) do.  The difference
> here is that structured subfields are used to contain actual values as
> opposed to location-dependent fields like is used in CNOS and CP
> Capabilities Exchange.  This will give us greater flexibility to grow
> the DLSw Capabilities Exchange over time.
>
Option (a) seems fine to me.  It does restrict each individual variable to
253 bytes, but that doesn't seem to be a major problem.  If it turns out to
be one in the future, we could always obtain more GDS ids for the large data
items at that time.

> Alternative (b) would enable us to logically group like elements
> together.  For example, all required variables could be in a GDS
> Variable; all pacing-related variables could be in another GDS
> Variable; all NetBIOS-related variables could be in yet another; and so
> on.  Not sure if this level of detail is worth the effort.
>
> Alternative (c) is just another way of representing variables as in
> alternative (a) but with GDS Ids rather than LT key values.  We have
> small variables and the overhead imposed by GDS Variables doesn't seem
> worth it.
>
> I don't think that nested GDS Variables like those in SNA/DS and DIA is
> the way to go either.  They impose a lot of overhead (per above
> argument) and parsing them is a pain unless you use yacc.  I've left
> that alternative out completely.
>
Agreed, but the concept of multiply-instanced LT structures may be useful (see
MAC Address List field below).

> Also, note that the structured subfields are all type LT (i.e. there
> are no KL subfields).
>
> I also think it is appropriate to establish a rule to enable backward
> compatibility of Capabilities Exchange:
>
>     If an implementation of DLSw doesn't recognize a particular
>     control vector, it is merely ignored.
>
> Please review and we'll discuss this next week along with IBM's
> TCP connection proposal.
>
> Regards,
> -----------
> Wayne Clark
> cisco Systems, Inc.
> [email-masked]
> 415/688-4627
>
> P.S. I won't have much time to do edits to this proposal based upon
>      feedback prior to the AIW ... I have to get the edits to the SDLC
>      MIB done this week.
>
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
> 			    Proposal for the Format of
>
> 			    DLSw Capabilities Exchange
>
>
> 				     Wayne Clark
> 			        cisco Systems, Inc.
>
>
> The Data Link Switching Capabilities Exchange is formatted as a single
> General Data Stream (GDS) Variable with multiple type "LT" structured
> subfields.
>
> The DLSw Capabilities Exchange looks like:
>
>     +----+----+-----------------+
>     | LL | ID | Control Vectors |
>     +----+----+-----------------+
>
>     0-1		Length, in binary, of the DLSw Capabilities Exchange GDS
> 		Variable.  The value of LL is the sum of the length of
> 		all fields in the GDS Variable (i.e. length of LL +
> 		length of ID + length of Control Vectors).
>
>     2-3		GDS Id: X'F000'
>
>     4-n		Control Vectors consisting of type LT structured subfields
> 		(i.e. the DLSw Capabilities Exchange Structured Subfields)
>
> 		Type LT structured subfields consist of a 1-byte length
> 		field (the "L"), a 1-byte type field (the "T") and n-bytes
> 		of data.  The length field defines the length of the
> 		structured subfield which, by definition, consists of the
> 		type field and data or n + 1.  This imposes a length
> 		restriction of 254 bytes on all data contained in a
> 		structured subfield.
>
>
>     DLSw Capabilities Exchange Structured Subfields
>
>         +---------------------------------------------------------------+
>         |   Vendor Id (X'01') Control Vector                            |
>         |                                                               |
>         |       The Vendor Id control vector identifies the             |
>         |       manufacturer of the Data Link Switch sending the DLSw   |
>         |       Capabilities Exchange.  This control vector is          |
>         |       required.                                               |
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'04'       Length of the Vendor Id structured
> 				    subfield
                        ****
Aren't LT structure lengths normally inclusive (as opposed to KL's)?

> 	   1       1    X'01'       key = X'01' that identifies this as the
> 				    Vendor Id structured subfield

I think the  five below should be a 4 (& similarly for all other vectors).
          ***
> 	  2-5      3                the 3-byte Organizationally Unique
> 				    Identifier (OUI) for the vendor
>
Who polices the uniqueness?

>
>
>         +---------------------------------------------------------------+
>         |   Version String (X'02') Control Vector                       |
>         |                                                               |
>         |       The Version String control vector identifies the	|
>         |       particular version number of the sending Data Link	|
>         |       Switch.  The format of the actual verion string is	|
>         |       vendor-defined.  This control vector is optional.	|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1   X'n-1'       Length of the Version String structured
> 				    subfield
> 	   1       1    X'02'       key = X'02' that identifies this as the
> 				    Version String structured subfield
> 	  2-n     n-2               the string that identifies the software
> 				    version for the sending DLSw.
>
>
>
>         +---------------------------------------------------------------+
>         |   NetBIOS Support (X'03') Control Vector                      |
>         |                                                               |
>     	|	The NetBIOS Support control vector identifies support	|
> 	|	for the NetBIOS protocol by the sending Data Link	|
> 	|	Switch.  This control vector is optional.  If it is	|
> 	|	ommitted in a DLSw Capabilities Exchange, then no	|
> 	|	NetBIOS support is assumed.				|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'02'       Length of the NetBIOS Support structured
> 				    subfield
> 	   1       1    X'03'       key = X'03' that identifies this as the
> 				    NetBIOS Support structured subfield
> 	   2       1                an indicator of the support for NetBIOS
> 				    by the Data Link Switch.
> 				    X'00'	NetBIOS is not supported by
> 						the sender
> 				    X'01'	NetBIOS is supported by the
> 						sender
>
>
>
>         +---------------------------------------------------------------+
>         |   Loop Prevention Support (X'04') Control Vector              |
>         |                                                               |
>      	|	The Loop Prevention Support control vector identifies	|
>      	|	support for the loop prevention algorithm as specified	|
>      	|	in the Data Link Switching specification.  This control	|
>      	|	vector is optional.  If it is ommitted in a DLSw	|
>      	|	Capabilities Exchange, then no Loop Prevention support	|
>      	|	is assumed.						|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'02'       Length of the Loop Prevention Support
> 				    structured subfield
> 	   1       1    X'04'       key = X'04' that identifies this as the
> 				    Loop Prevention Support structured subfield
> 	   2       1                an indicator of the support for Loop
> 				    Prevention by the Data Link Switch.
> 				    X'00'	Loop Prevention is not
> 						supported by the sender
> 				    X'01'	Loop Prevention is supported
> 						by the sender
>
>
>
>         +---------------------------------------------------------------+
>         |   Flow Control Support (X'05') Control Vector                 |
>         |                                                               |
> 	|	The Flow Control Support control vector identifies the	|
> 	|	level of support for flow control for the sending Data	|
> 	|	Link Switch.  This control vector is optional.  If it	|
> 	|	is ommitted in a DLSw Capabilities Exchange, then no  	|
> 	|	flow control support is provided by the sender.		|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'03'       Length of the Flow Control Support
> 				    structured subfield
> 	   1       1    X'05'       key = X'05' that identifies this as the
> 				    Flow Control Support structured subfield
> 	   2       1                an indicator of the different flow control
> 				    techniques implemented by the sender.
> 				    Bit	   Contents
> 				    ---	   --------
> 				     0	   indicator for support of XON / XOFF
> 					   flow control
> 					   0	XON / XOFF flow control is not
> 						supported.
> 					   1	XON / XOFF flow control is
> 						supported.
> 				     1	   indicator for support of fixed
> 					   window pacing
> 					   0	fixed window pacing is not
> 						supported
> 					   1	fixed window pacing is
> 						supported
> 				     2	   indicator for support of variable
> 					   window pacing
> 					   0	variable window pacing is not
> 						supported
> 					   1	variable window pacing is
> 						supported
> 	   3       1                an indicator of  which flow control
> 				    technique is in effect by the sender.
> 				    X'80'	XON / XOFF flow control is
> 						in effect.
> 				    X'40'	fixed window pacing flow
> 						control is in effect.  If this
> 						value is specified, the
> 						Initial Pacing Window control
> 						vector must be specified.
> 				    X'20'	variable window pacing flow
> 						control is in effect.
> 				    X'00'	no flow control is in effect
>
This will probably need to be re-visited in the light of the Flow Control
discussions next week.  Peter Gayek's current proposal would not use byte 3 as
the mechanism in use is chosen independently by both DLSw partners.

We will need to discuss this next week.

>
>
>         +---------------------------------------------------------------+
>         |   Initial Pacing Window (X'06') Control Vector                |
>         |                                                               |
> 	|	The Initial Pacing Window control vector specifies the	|
> 	|	pacing window size for either fixed window or variable	|
> 	|	window pacing schemes.  For fixed window pacing, this	|
> 	|	value is the window size for the life of the TCP	|
> 	|	connection.  For variable window pacing, this value is	|
> 	|	the initial window size.  This control vector is	|
> 	|	required if the Flow Control Support control vector	|
> 	|	indicates either fixed or variable window pacing is in	|
> 	|	effect.							|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'03'       Length of the Initial Pacing Window
> 				    structured subfield
> 	   1       1    X'06'       key = X'06' that identifies this as the
> 				    Initial Pacing Window structured subfield
> 	  2-3      2                the pacing window size.
>
>
>
>         +---------------------------------------------------------------+
>         |   MAC Address Mask (X'07') Control Vector                     |
>         |                                                               |
>         |       The MAC Address Mask control vector specifies the mask	|
>         |       to use for identifying ranges of MAC addresses that are	|
>         |       accessible by the sending Data Link Switch.  This	|
>         |       control vector is used in conjuction with the MAC	|
>         |       Address Value Control Vector to identify this  range of	|
>         |       accessible MAC addresses.				|
>         |                                                               |
>         |       Note: If a particular MAC address, <mac-addr>,		|
>         |             satisfies the following algorithm, then		|
>         |             <mac-addr> is assumed to be accessible via the	|
>         |             sending Data Link Switch.				|
>         |                                                               |
>         |             <mac-addr> & <mac-addr-mask> == <mac-addr-value>	|
>         |                                                               |
>         |                 where:  <mac-addr-mask>  is specific in this	|
>         |                                          control vector, and	|
>         |                         <mac-addr-value> is specified in the	|
>         |                                          MAC Address Value	|
>         |                                          control vector.	|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'07'       Length of the MAC Address Mask
> 				    structured subfield
> 	   1       1    X'07'       key = X'07' that identifies this as the
> 				    MAC Address Mask structured subfield
> 	  2-7      2                the 6-byte MAC address mask
>
>
I may have missed (or forgotten) some mailings because I cannot see how these
fields fit with the recent proposals, though some form of topology data could
be useful.  However in order to remain useful, wouldn't this data have to
be exchanged more often than just at the start of a connection between DLSw
partners?

If we do adopt a scheme such as this for, essentially, pre-loading each
partner's MAC table, I feel that the MAC Address List structure is the most
generally useful of these three variables.  Certainly any organization using
universally administered MAC addresses is going to have trouble using the
MAC address mask.

My apologies if I am going back over old ground here.  If so, can someone
point me in the direction of the mailings I have missed.

>
>         +---------------------------------------------------------------+
>         |   MAC Address Value (X'08') Control Vector                    |
>         |                                                               |
>         |       The MAC Address Value control vector specifies the	|
>         |       value to use for identifying ranges of MAC addresses	|
>         |       that are accessible by the sending Data Link Switch.	|
>         |       This control vector is used in conjuction with the MAC	|
>         |       Address Mask Control Vector to identify this range of	|
>         |       accessible MAC addresses.				|
>         |                                                               |
>         |       See MAC Address Mask Control Vector for an		|
>         |       explanation.						|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'07'       Length of the MAC Address Value
> 				    structured subfield
> 	   1       1    X'08'       key = X'08' that identifies this as the
> 				    MAC Address Value structured subfield
> 	  2-7      2                the 6-byte MAC address value
>
>
>
>         +---------------------------------------------------------------+
>         |   MAC Address List (X'09') Control Vector                     |
>         |                                                               |
>         |       The MAC Address List control vector specifies a list of	|
>         |       MAC addresses that are accessible by the sending Data	|
>         |       Link Switch.  Because of the limitations of the		|
>         |       single-byte length field, a maximum of 42 MAC addresses	|
>         |       can be defined.						|
>         |                                                               |
>         |       This control vector can be used in conjunction with the	|
>         |       MAC Address Mask / MAC Address Value control vectors.	|
>         |                                                               |
>         +---------------------------------------------------------------+
>
>
> 	Offset  Length  Value       Contents
> 	------  ------  -----       --------
> 	   0       1    X'n-1'      Length of the MAC Address List
> 				    structured subfield
> 	   1       1    X'09'       key = X'09' that identifies this as the
> 				    MAC Address List structured subfield
> 	  2-n     n-2               the list of 6-byte MAC addresses. A
> 				    maximum of 42 contiguous MAC addresses
> 				    can be specified.
>
We could get round the 42 MAC address limit by allowing multiply-instanced LT
variables (c.f. SNA/FS Global File Name structures).  These are still easy to
parse as long as we enforce ordering of the LT variables i.e. a sequence of
vectors 1,2,..8,9,9 is valid but 1,2,..7,9,8,9 is not.  Each additional
batch of MAC Address List data is simply parsed to pre-load the MAC table in
the same way as you would if there was only one such set of data.

We should also define how multiple-instances of the other vectors should be
handled.  For example, if a DLSw receives a Capabilities Exchange with, say, 2
Vendor ID vectors, it could choose any of the following courses of action:

-       drop the connection (my preferred option)
-       ignore the first vector
-       ignore the second vector.

We need to mandate what action is to be taken in order to avoid
inter-operability problems.

---

From: [email-masked]
Date: Wed, 09 Feb 94 11:37:21 PST

Paul -

    Thank you for your quick feedback.  I've included my responses below.

See you in Anaheim,
Wayne

>        GDS variable you propose.

    We agreed at the last AIW to have the Capabilities Exchange be just
    another SSP message over a TCP session between a pair of
    cooperating DLSw-capable routers.  We haven't assigned a value to
    the message type yet.

    I was hoping Steve Klein's SSP Message Types assignment email would
    have one, (Ref:  "Updated RFC 1434 FSMs" , Steve Klein, 01/24/94)
    but we really didn't make the formal request for one :-).  We will
    definitely make the request next week.

>-       When exactly does the exchange occur - as the first message only?

    At the present time, it will be the first message only.  There was
    some discussion from IBM at the last AIW (I think from Gene Cox)
    that we might want to also allow Capabilities Exchange after connections
    have been established to reflect run-time changes in the DLSw-capable
    router.

    I think this is a good idea but should be deferred until later in
    a future specification of DLSw.  However, we should discuss it
    next week (see below).

>        in with the how the exchange is sent over the SSP transport.

    The direction we were leaning is that backrev implementations of
    DLSw (e.g. IBM 6611 and Proteon) would be able to accept a foreign
    SSP message (i.e. Capabilities Exchange) but just ignore it.  The
    lack of a Capabilities Exchange back from a DLSw participating
    router (withing some time interval) would be a signal that it is a
    backrev DLSw.

    I believe the onus is on the vendors of backrev implementations to
    accept and ignore foreign SSP messages.  If a DLSw standard-compliant
    router wants to communicate with a backrev DLSw (i.e. today's 6611
    or a pre-standard Proteon/Wellfleet/ascom/etc.), then it must have
    the capabilities timeout logic and appropriate SSP protocol fallback
    logic to do this.

>More detailed points comments are listed in the message appended below.

    Great ... looking forward to it.  Thanks for your input.

>Paul Brittain

    The only problem that I see at the moment with the 1-byte length
    specification is in the MAC Address List Control Vector below.

    In think we ought to discuss this next week when we review the
    format proposal.

>MAC Address List field below).

    Yes, this is a possible solution for the LT length limitation. We
    should discuss this in the SIGlet meeting.  I'll email out a
    detailed agenda for the SIGlet late Thursday so people have
    something to think about over the weekend (or on long plane
    flights!).

>Aren't LT structure lengths normally inclusive (as opposed to KL's)?

    I also thought that the L in LT included itself but I went back and
    looked at the LT subfields in the User Data Field of the BIND image
    (e.g. Mode Name) and the L covered only T + data.

    Note however that this conflicts with the description of LT control
    vectors at the start of Chapter 8 of the SNA Formats manual.  There
    it says that L covers L + T + data.  Even the latest Formats
    manual (the -13) has the same statement.

>I think the  five below should be a 4 (& similarly for all other vectors).

    Oops ... you're right.

>Who polices the uniqueness?

    The IETF assigns them.  The current assignments are in RFC1340.

>>      	|	is assumed.					
>	|

    Agreed.  I was holding off submitting this format proposal until
    flow control converged on a solution but ran out of time :-).

    I intend to ask Louise Wells to schedule the Capabilities SIGlet
    last so we know what the full story is on the other SIGlets before
    we meet to discuss Capabilities.

>>         |                                          control vector, and
>	|

    You haven't missed any mailings.  It was proposed by IBM at the last
    AIW and reflected in the minutes but has not enjoyed any email discussion.
    I accept responsibility for this shortsightedness.

    I believe most of the useful information regarding accessible MAC
    addresses would be available at startup time.  Sure, new MAC addreses
    are learned through the normal operations of the switch but I believe
    the main intent of this information was to define initial sysdef'd
    MAC addresses to the partner DLSw.

    We can discuss this next week.

>>         |       can be defined.					
>	|

    Agreed ... I've just placed this onto the agenda for next week.

Thanks a lot for your input,
Wayne

---

From: [email-masked] (Susie Kim Riley)
Date: Thu, 10 Feb 94 09:07:56 EST

>    router (withing some time interval) would be a signal that it is a

I might have missed a former discussion about the exact header format
for the new capabilities exchange message.  Am I correct in assuming
that the SSP Control Header will have the same format in the
capabilities exchange message?  
In order for existing implementations of DLS to be able to accept the
capabilities exchange messages (and not die on impact), we must make
sure that no new message FORMAT types are introduced - i.e., all
messages have the generic message header of 16 bytes, and control
messages have the extended control message fields.

SKR

---

From: [email-masked]
Date: Thu, 10 Feb 94 07:33:38 PST

>capabilities exchange message?  

    I think it is safe to assume that the SSP message format will be the
    same with Capabilities Exchanges as it is with all other SSP message
    types.  Even though that has not been officially stated as an upodate
    to the spec, it was the consensus to approach it in this way.

    I've attached the Capabilities Exchange matrix below.  Please check
    out the "Feature: TCP vs. UDP for Capabilities Exchange" section.
    Also, it was in the minutes from the Capabilities SIGlet at AIW3.

Wayne Clark
cisco

>messages have the extended control message fields.

		      DLSw Capabilities SIGlet

			     Feature List

		    Wed Sep 22 19:17:44 PDT 1993

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Base Set vs. Option Sets
    Description:	What features in ODLS should be base requirements for
			interoperability and which ones should be optional.
    Member Input:
	Cayman		Base   = RFC 1434 + capab exchng + flow control
			Option = name server
	Novell		Option = NetBIOS support
	Eicon		Base   = (today's) DLSw (i.e. default capabilities)
	3Com		Option = loop prevention
	Eicon		Option = directory service
	Wellfleet	Base   = RFC 1434
			Option = SIG effort
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Vendor Id
    Description:	Include a vendor id, vendor release number, etc. in
			the capabilities exchange.
    Member Input:
	Cisco		Vendor id is a good thing.
	Wellfleet	Wary about vendor id.
	Proteon		Vendor id is a good thing.  Aids in problem det.
	Cayman		Don't like vendor id.  Invites variations.
	Hypercom	Vendor id is a good thing.  Aids in problem det.
	Novell		Vendor id is a good thing.  Good for troubleshooting.
	Eicon		Vendor id is a good thing.  Ignoring it is ok.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	TCP vs. UDP for Capabilities Exchange
    Description:	Transport of the capabilities across TCP or UDP.
    Member Input:
	Cisco		TCP or UDP, with a preference for UDP.
	Novell		TCP only.  For reasons of alternate transport.
	BBN		TCP only.  For reasons of alternate transport.
	Wellfleet	TCP only.  Use another SSP message within TCP.
	Cayman		TCP only.  Use another SSP message within TCP.
	Hypercom	Leaning toward UDP.
	Ascom/T-plex	TCP only.  Use another SSP message within TCP.
			Concerned about requiring IP multicast.
	Eicon		TCP only.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Data Stream Format
    Description:	How should the capabilities exchange data stream
			be formatted?
    Member Input:
	Cisco		GDS format (i.e. LLID).
	Novell		GDS format (i.e. LLID).
	Cayman		Tag / length. (i.e. like GDS = editor note)
	Hypercom	GDS format (i.e. LLID).
	Eicon		GDS format (i.e. LLID).
	Wellfleet	GDS format (i.e. LLID).
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Optional CANUREACH / ICANREACH
    Description:	Should CUR/ICR be optional at connection startup?
    Member Input:
	Cisco		They should be optional.  Must be able to send/recv.
	Novell		Ability to suppress sending CANUREACH.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Directory Server / Name Server
    Description:	How should ODLS-capable routers find out about each
			other?
    Member Input:
	Radlinx		List of already-known ODLS routers in capabilities
			exchange.
	Hypercom	Name server treading onto APPN turf. Objective, but
			not in the base.
	Cisco		List of already-known ODLS routers in capabilities
			exchange.
	Novell		List of ODLS routers in capabilities exchange.  Don't
			want it link state-based.
	Eicon		Directory Service could be a good idea but should
			not be addressed now.
	Wellfleet	Directory Server should be a future service. Leave
			out until further investigation.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+